Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/hubmib/hubmib-minutes-91nov.txt

Text File | 1993-02-17 | 21.0 KB | 551 lines

CURRENT_MEETING_REPORT_


Reported by Donna McMaster/SynOptics

Minutes of the IEEE 802.3 Hub MIB Working Group (HUBMIB)

The meeting was called to order by Co-Chairs Keith McCloghrie and Donna
McMaster.

Agenda


   o Introduction
   o Chassis MIB presentation (Keith)
   o Repeater ID discussion and resolution
   o Report on IEEE 802.3 Hub Management ballot (Donna)
   o Discussion of outstanding issues


      -  From Section 8 of the current draft
      -  From the mailing list since the Atlanta meeting
      -  New issues


There were no changes to the draft, mailing list, or archive site since
the last meeting.  The current draft is still the July 22, 1991 version.
The Working Group mailing list is [e-mail].  Requests should
be sent to [e-mail].  Drafts and mail are archived
in pub/hubmib on sweetwater.synoptics.com, and can be accessed using
anonymous ftp.

Donna will add all meeting attendees to the hubmib mailing list.

Chassis MIB

There has been significant discussion about the repeater ID. Several
parties have expressed the opinion that the repeater ID is not the best
solution to the problem of managing multiple repeaters with a single
agent, but that the problem needs to be addressed.

Keith presented an alternate proposal, dubbed a ``Chassis MIB.'' This
MIB defines objects for managing a ``box'' containing assorted network
devices such as repeaters, bridges, routers, and/or terminal servers.
Keith's slides are reproduced below.

  CHASSIS MIB

    How to manage a box containing multiple modules.
    o  Multiple Physical Modules - slots
    o  Multiple Logical Devices - repeaters, bridges, etc.
    o  Multiple Backplane ``Wires'' - Ethernet, Token Ring, FDDI, etc.
    o  Power Supply - need separate MIB

                                   1






  PHYSICAL DEVICE TABLE

    What's in the Slot ?
    o  Index by slot-number
    o  Board Type - an OID, common values defined for empty and unknown
    o  Last change - sysUpTime at last insert/removal

  LOGICAL DEVICE TABLE

    o  Index by integer
    o  Function - a sum of values, one value for each of repeater,
       bridge, router, terminalServer, management card, etc.
    o  ObjectId = sysObjectId
    o  Party - a SNMP party OID, or `noParty'
    o  Community - community-string or empty
    o  IpAddress - IP Address for use with community

  BACKPLANE WIRES TABLE

    o  Indexed by integer
    o  Type - an OID
    o  Other ??

  RELATION TABLE

    Which device(s) are in which slot(s) and connected to what wires on
    the backplane
    o  Each entry represents one relation
    o  Each entry contains three pointers:
    o  1st pointer is the slot number
    o  2nd pointer is the logical device index
    o  3rd pointer is the backplane wire index

    An entry means that the module in the indicated slot is (part of)
    the indicated logical device and is connected to the indicated
    backplane wire.

  EXAMPLE

          Slot         Device         Backplane
            1             1               1
            2             1               1
            3             2               1
            3             2               2
            4             3               2
            5             3               2

          devices 1,3 are repeaters; device 2 is a bridge.

Vigorous discussion ensued.  There were many questions, and general
enthusiasm.  Some of the issues raised:


                                   2





   o Questions about physical vs.  logical devices

   o Use netAddr instead of IP address

   o Multiple addresses for the same agent (router, or OOB): could make
     multiple entries in the device table.  Would need an additional
     index variable for the table.

   o What community string does each device send in traps -- that is, if
     one agent represents multiple repeaters, how does the trap receiver
     determine which repeater is referenced by the trap?



The enthusiasm threatened to use all the time allocated for discussion
of repeater MIB issues, so a straw poll was taken to see if a new effort
should be undertaken to develop a Chassis MIB. Straw poll question:  Do
people believe that the development of a Chassis MIB is a useful and
feasible project?  Strong consensus that a Chassis MIB is both useful
and feasible, no opposition was expressed.

Repeater ID

Keith briefly recapped the repeater ID issue and opened the floor to
debate.  Several people expressed the opinion that the repeater ID is
not the appropriate mechanism for handling multiple repeaters, and that
energy should be directed instead toward development of a Chassis MIB.

No one was speaking in favor of the repeater ID, so a straw poll was
taken.  Twelve people indicated preference for dropping the repeater ID;
one (Jeff Case) wanted to keep the ID. When asked for comment, Jeff
explained that it was a simple solution to a current, real problem, but
that he knew better than to fight overwhelming odds.

Donna presented a letter from IEEE 802.3 Hub Management members Kathy de
Graaf (DAVID Systems), Steve Horowitz (Chipcom), and Jim Reinstedler
(Ungermann-Bass), arguing to keep the repeater ID. Their conclusion is
that the repeater ID ``provides a simple, inexpensive, standard,
interoperable, and useful way of allowing a single agent to address
multiple repeaters.''  (Full text of the letter will be published in the
Proceedings.)  Discussion was invited; no one had changed his/her
opinion.  No representatives from Chipcom or Ungermann-Bass were present
to comment.  Mark Schaefer from DAVID Systems declined to comment on the
letter, saying that he personally prefers the Chassis MIB solution.

In light of the strong consensus, the Working Group officially decided
to remove the repeater ID from the MIB, effectively making the MIB
definitions represent a single repeater instead of a collection of
repeaters.

IEEE Report

Donna presented a summary of IEEE 802.3 Hub Management Task Force (802.3

                                   3





HMTF) activities.  The 802.3 HMTF circulated a draft for letter ballot
in early August.  The draft received 325 comments from 64 balloters,
with an initial approval rate of 71 percent.  All comments were
addressed in meetings held at the IEEE 802 Plenary November 10-15.
Enough comments were favorably resolved to raise the approval rate above
the 75 percent needed to consider the ballot formally passed.

802.3 HMTF made a number of changes in their draft as a result of the
comment resolution process.  A new draft will be mailed out for
confirmation ballot in December, closing in January.  (The confirmation
ballot process is intended to verify that changes address voters'
concerns without creating new problems.)

The overall 802.3 Working Group also chartered new activities for
defining MAU management information and for rewriting the current 802.3
layer management standard in the ISO GDMO format.  The MAU management
effort will include such information as media type (e.g., 10BASE-T or
coax) and link status.

A summary of the major changes being made in the 802.3 Hub Management
draft:


  1. The term ``hub'' is being changed to ``repeater.''

  2. The SNMP encodings in Annex B are being replaced with a reference
     to the work of the IETF Hub MIB Working Group.

     Case questioned whether IEEE was dropping the SNMP encodings
     because they consider SNMP to be a ``substandard'' management
     protocol.  Donna stated that 802.3 uses ISO GDMO encodings because
     their standards are forwarded to ISO after adoption by IEEE.
     Removing the SNMP encodings was done to acknowledge that the IEEE
     does not believe it appropriate to ``compete'' with the IETF in
     developing SNMP MIBs.

     However, the 802.3 HMTF is very interested in SNMP, and most of the
     companies represented in that group are implementing SNMP
     management of their repeaters.  Given that strong level of interest
     in SNMP, their action indicates a willingness to ``trust'' the IETF
     Hub MIB Working Group.

  3. The concept of ``groups'' was modified in several ways.  The
     ``group'' concept has always been a logical concept with references
     to possible physical mappings.  In the new draft, all references to
     physical embodiments of groups are being removed, making a group a
     purely logical construct.

     The group definition has also been changed to allow non-contiguous
     port numbering, and to allow ports to be added to groups or removed
     from groups without resetting management.  Previously, a group had
     a fixed number of ports ``N'', and the ports in the group were
     numbered from 1 through N. To effect this change, the

                                   4





     groupNumberOfPorts attribute was replaced with groupPortCapacity,
     and a groupPortMap attribute was added.

     These 802.3 HMTF port/group changes generated much discussion in
     the IETF Hub MIB Working Group, detailed in section V below.

  4. The repeater-level MJLPs counter was replaced with a per-port
     equivalent called ``veryLongEventReceived'' counter.

  5. ExecuteSelfTest2 was considered to be redundant with the resetHub
     command, and was eliminated.  ExecuteSelfTest1 was renamed to be
     execNonDisruptiveSelfTest.

  6. One balloter suggested that hubHealthData should be left for vendor
     extensions, as it cannot be interpreted in a vendor-independent
     manner.  After some discussion, 802.3 HMTF decided to keep
     hubHealthData as ``an opportunity for implementation agreements.''

  7. The shortEvents and runts counter definitions were changed, and
     several other counter definitions were made more clear.  The
     ``runtMaxTime'' number (that differentiates between a long but
     legal collision fragment and a late collision) was debated and left
     unresolved.  A conference call between repeater experts is being
     scheduled, and 802.3 HMTF agreed to let the members of the
     conference call specify the value to be used.



The next questions for the Hub MIB Working Group (IETF flavor) are
whether to incorporate these 802.3 HMTF changes in our draft, and if so,
when the changes should be made.  All agreed that technical changes to
counter definitions must be reflected in the IETF MIB. We also agreed to
wait until after the confirmation ballot closes so that our draft
doesn't thrash unnecessarily.

When the confirmation ballot is complete, Donna will convey the ballot
results to the Working Group along with a proposal for incorporating
changes.

Draft Status

Jeff Case suggested the draft might be ready for forwarding to Proposed
Status.  There were mutterings of concern over changes that might be
made in this meeting.  Agreement was reached to postpone the question
until later in the meeting.

We later agreed that we will not forward the document to the IESG. The
editors will update the draft with changes from this meeting and from
the IEEE confirmation ballot, and publish for discussion at the next
IETF meeting.  The goal will be approval of the Working Group and
submission as recommended for Proposed Standard status.



                                   5





Groups of Ports

(In reference to IEEE item 3, above.)  The Hub MIB Working Group members
shared a strong consensus that the reason for defining port groups is to
assist the user in mapping the port numbers to the physical devices.
This is in direct opposition to the IEEE's direction of stating that the
group mapping is purely logical.  The Working Group agreed that the
draft will continue to state that implementors may assign group and port
numbers as desired, but that we strongly recommend that group and port
mappings match the physical manifestation of the repeater as closely as
possible.

The Working Group agreed to accept the IEEE's change to allow ports
within a group to come and go.  Does this imply a need for portUpTime as
well as for groupUpTime?  This would add complexity to every
implementation whereas having ports moving between groups/repeaters is
expected to be the less common case.  Much discussion, decided not to
add portUpTime.

Discussion of portMap.  The Working Group observed that this information
can be deduced from other existing objects in a single powerful Get-Next
PDU (though not in a single wimpy Get PDU), and also observed that this
configuration information will not change frequently.  The same applies
to the groupMap.  Both groupMap and portMap are therefore redundant, and
there was a general feeling that the overhead of collecting the
information does not justify the optimization of packaging the
information into a bit map.  We decided that groupMap will be removed,
and we will not add portMap.

How to handle the table rows for groups that are removed from a repeater
or ports that are removed from a group?  Delete the rows?  Or have a
state column in the table with a ``not here'' value to indicate a
port/group that has trotted off into the sunset?  Jeff Case:  in other
such cases, we have left this to the discretion of the implementor.
There was general agreement that the implementor should choose when it
is appropriate to remove the table row and when it is appropriate to
return a state indicating that the group/port is unavailable for
service.

It was further observed that ``not here'' could mean ``switched to the
other repeater in this box'' or it could mean that a plug-in module was
removed or had failed.  There was some discussion about having an
operState column that could be used for various flavors of broken or
``not here.''  This idea was greeted favorably, and discussed with other
objects later in the meeting (below).

Issues from Draft Section 8

Some of the section 8 issues had been previously resolved; we covered
them briefly just for completeness.  Numbers below correspond to Section
8 headings.

8.1.  Optional groups:  agreed to keep all three groups (mandatory
Basic, optional Monitor and Address Tracking).

                                   6





8.2.  Multiple repeaters:  removing repeater ID, see II above.

8.3.  System objects (rptrBasManufacturer, rptrBasProduct,
rptrBasVersion):  agreed to take them out.

8.4.  Health information:  Agreed to take out rptrHealthData.  Should be
in vendor-specific MIBs, since it cannot be decoded in a standard way.
``If people implement this instead of something that users can
understand, we've done a disservice.''

8.5.  Additional group information:  Keith showed a matrix of
administrative objects relating to repeater, groups, and ports, and the
Working Group discussed which administrative objects should be included
for each of the three.  The resulting table is shown below.  The only
changes from the current draft are in the operState column.  Details of
the proposed changes are listed below the matrix.



----------+-----------+-----------+-----------+-----------+-----------
          |  admin    |  oper     |  reset    |  self     |  upTime
          |  state    |  state    |           |  test     |
----------+-----------+-----------+-----------+-----------+-----------
repeater  |  NO       |  YES (1)  |  YES      |  YES      |  NO
----------+-----------+-----------+-----------+-----------+-----------
group     |  NO       |  YES (2)  |  NO       |  NO       |  YES
----------+-----------+-----------+-----------+-----------+-----------
port      |  YES      |  YES (3)  |  NO       |  NO       |  NO
----------+-----------+-----------+-----------+-----------+-----------



  1. Rename rptrHealthState to be rptrOperState.
  2. Add new groupOperState object.
  3. Add new portOperState object.  Some discussion about whether this
     should be combined with autoPartitionState.  Donna disagreed,
     because autoPartitionState is very specifically defined for
     repeater hardware.  Agreed to define enumerations for portOperState
     and see then whether combining with autoPartitionState makes sense.



8.6.  Carefully-crafted counter comments:  committee condemns; clearly
cannot condone.

Issues from Mailing List

Keith had slides listing all issues discussed on the mailing list since
the last meeting, and the Working Group addressed each of them in turn.

Broadcast, Multicast Counters:  These were not included in IEEE and
earlier IETF drafts because they can be collected by a promiscuous

                                   7





monitor anywhere in the unbridged LAN segment and mapped to senders
using the packets' source addresses.  After discussion, there was
agreement not to add broadcast, multicast counters.

Total Counters Discussed optimizing the collection of counts for a
repeater by offering repeater (or even group?)  total counts.  This
issue is similar to the portMap/groupMap issue, but counters (esp.
errors) need to be collected much more frequently in order to track the
health of the network.  Also, it is not unusual for a single repeater to
have over 100 ports, causing high collection overhead.

After discussion, the Working Group agreed that total counts are
appropriate for some set of information.  Proponents of totals are asked
to submit proposed sets of total counters to the mailing list for
further discussion.

Suggestion from Bob Faulk regarding address search object:  No one
expressed interest in pursuing this proposal, and it was suggested that
it was more appropriate as a vendor extension.

New Issues

No new issues were brought up, primarily due to lack of time.

IEEE 802.3 Hub Management Letter



To:     Donna McMaster
        Keith McCloghrie
        Repeater Management MIB Working Group
        IETF

From:   Kathy de Graaf
        Steve Horowitz
        Jim Reinstedler

For over two years we, as members of the IEEE 802.3 Repeater
Management Task Force, have worked very hard to  develop a standard for
managing IEEE 802.3 repeaters.  802.3 has approved the current draft in a
letter ballot, and on November 14, 1991 affirmed this work by voting
overwhelmingly to send the current draft to a confirmation ballot.

 The members of the 802.3, representing almost all the major hub vendors,
have considerable experience not only in instrumenting but also in
configuring manageable hubs.  Although much of this draft is directed toward
instrumentation for fault and performance management,  considerable effort
was also expended to model the real repeater products that exist in the
marketplace.

A repeater is frequently implemented as one or more cards in a  modular
hub having  multiple backplane connections and with a single agent
managing the hub.  These hubs may contain multiple repeaters and have the
ability to dynamically create and delete groups of ports or individual ports.

                                   8





While not all products have all these features, we did reach a consensus on
features in the repeater MIB that correctly and usefully model either a high-
end or low-end repeater without unduly burdening the simpler repeaters.

Two years ago only a minority of the task force supported attributes that
were primarily for configuration, but as we realized (from discussion and
implementation) that it was both practical and desirable to provide such
attributes, an overwhelming and persistent consensus developed in their
favor.

One example that has recently been controversial in the IETF is the use of
hubID (now repeaterID) to distinguish one of many repeaters within a hub
enclosure.  We have found  that this provides a simple,  inexpensive,
standard, interoperable, and useful way of allowing a single agent to address
multiple repeaters, and thus urge that it  be retained.

We, as members of the IEEE 802.3 Repeater Management task force,
therefore hope that the RM MIB Working Group will consider preserving
not only the IEEE attributes directed towards fault and performance
instrumentation, but also those provided for configuration management.



Attendees

Miriam Amos Nihart       [e-mail]
Karl Auerbach            [e-mail]
Steve Bostock            [e-mail]
David Bridgham           [e-mail]
Jeffrey Case             [e-mail]
James Codespote          [e-mail]
Dave Cullerot            [e-mail]
James Davin              [e-mail]
Michael Erlinger         [e-mail]
Jeff Erwin
Bill Fardy               [e-mail]
Shawn Gallagher          [e-mail]
Greg Hollingsworth       [e-mail]
Satish Joshi             [e-mail]
Frank Kastenholz         [e-mail]
Manu Kaycee              [e-mail]
Yoav Kluger              [e-mail]
Cheryl Krupczak          [e-mail]
Ron Lau                  [e-mail]
Keith McCloghrie         [e-mail]
Evan McGinnis            [e-mail]
Donna McMaster           [e-mail]
David Minnich            [e-mail]
Lynn Monsanto            [e-mail]
Anil Rijsinghani         [e-mail]
Mark Schaefer            [e-mail]
Timon Sloane             peernet![e-mail]
Bob Stewart              [e-mail]
Bruce Taber              [e-mail]

                                   9





Iris Tal                 [e-mail]
June-Kang Yang           natadm![e-mail]
John Ziegler             [e-mail]



                                  10